Methods and systems for linking an electronic address to a physical address of a customer

ABSTRACT

An electronic account links an electronic address to a physical address of a customer. Services provided to the customer using the electronic account can be delivered to the physical address or the electronic address of the customer. If the customer requests to receive only physical mail, the link between the addresses can be used to deliver any electronic mail to the physical address of the customer.

I. RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional PatentApplication No. 60/189,983 with a filing date of Mar. 17, 2000, which isincorporated herein by reference.

II. BACKGROUND OF THE INVENTION

[0002] A. Field of the Invention

[0003] The present invention relates to systems and methods forproviding electronic communications to a customer. More particularly,the invention relates to systems and methods for providing an electronicaccount and other services to a customer by linking the customer'selectronic address to a physical address where the customer receivesphysical mail.

[0004] B. Description of the Related Art

[0005] The United States Postal Service (USPS) is an independentgovernment agency that provides mail delivery and other services to thepublic. The USPS is widely recognized as a safe and reliable means forsending and receiving mail. With the steady growth of electroniccommunication and commerce, consumers and businesses need a secure wayto communicate and conduct business electronically. Without trustworthychannels of communication, many potential participants in electroniccommerce are unwilling to send sensitive information, e.g., credit cardnumbers, electronically, thus limiting the utility of electroniccommerce to all individuals.

[0006] Electronic mail, or e-mail, is a well-known means ofcommunication for individuals and businesses with access to computersand Internet connections. When a user establishes an account with ane-mail service provider, e.g., America Online™ or Hotmail™, the user isassigned a unique e-mail address, e.g. joesmith@aol.com. Anotherindividual can send a message to the user by entering the user's e-mailaddress along with the message and sending it via the Internet. E-mailcan provide almost instant message delivery among individuals andbusinesses over vast distances for very little or no cost. E-mail alsopresents an opportunity for businesses to advertise to potentialcustomers in a new way, e.g., by sending bulk advertisements via e-mail.

[0007] Despite the advantages of e-mail, there are several drawbacks.Because e-mail is received and viewed electronically, e-mail does notreach those who are not “online.” In this way, e-mail contributes to theso-called “technology gap” between individuals with access to computersand computer technology and individuals who cannot afford or who do notunderstand computers and computer technology.

[0008] Additionally, the simplicity and low cost of e-mail make it aneasy vehicle for unwanted messages, e.g, unsolicited advertisements or“spam.” Both individuals and businesses demand the capability to inhibitthe receipt of unwanted e-mail.

[0009] Furthermore, e-mail messages are also insecure, and can beintercepted en route by unknown third parties. Businesses and consumerswho communicate electronically need to know that their messages areprivate, and that they can rely on the address to correctly identify thesender and/or recipient.

[0010] Therefore, it is desirable to provide a system for communicatingelectronically that is available to everyone, that gives consumerscontrol over the content of communications received, and that provides asecure and reliable way to conduct transactions electronically.

III. SUMMARY OF THE INVENTION

[0011] Systems and methods consistent with the present inventionovercome the shortcomings of conventional systems by establishing anelectronic account for a customer on a network, where the customer'selectronic address is linked to the customer's physical address. As witha conventional electronic account, a customer is able to send andreceive e-mail, as well as conduct electronic transactions. However, theelectronic account ensures flexible and secure communications by linkinga customer's electronic address to the customer's physical address.Systems and methods consistent with the present invention may beimplemented by the USPS. Moreover, such a USPS electronic account mayprovide electronic access to all persons, i.e., a person with a USPSphysical address may also have a USPS electronic account.

[0012] A method consistent with the present invention determines astandardized physical address of a user with an electronic account bysending a query from an address matching engine to an address matchingdirectory database. The address matching directory database retrievesthe standardized physical address of the user based on the query andsends the standardized physical address to the address matching engine.The standardized physical address is linked to the electronic account.

[0013] Another method consistent with the present invention determines astandardized physical address of a user with an electronic account byobtaining a delivery point identification key corresponding to aphysical address of the user and storing the delivery pointidentification key in the electronic account. When the delivery pointidentification key is sent to an address database, the standardizedphysical address corresponding to the delivery point identification keyis received from the address database.

[0014] Another method consistent with the present invention delivers aphysical message in an electronic format to a plurality of users with anelectronic account and a physical address. When the physical messagedirected to the physical address for each of the users is received, anelectronic address for each of the users is determined from the physicaladdress of each user, and the physical message is sent in an electronicformat to the electronic address for each of the users.

[0015] It is to be understood that both the foregoing generaldescription and the following detailed description are exemplary andexplanatory only and are not restrictive of the invention, as claimed.

IV. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in andconstitute a part of this specification, illustrate several embodimentsof the invention and, together with the description, serve to explainthe principles of the invention.

[0017] In the drawings:

[0018]FIG. 1 is a high level block diagram of a system for providing anelectronic account to a customer;

[0019]FIG. 2 is a high level block diagram of a system for linking anelectronic address to a physical address of a customer;

[0020]FIG. 3 depicts one embodiment of a link between an electronicaddress and a physical address of a customer;

[0021]FIG. 4 is a high level block diagram of a system for providingservices to a customer using an electronic account consistent with thepresent invention;

[0022]FIG. 5A is a high level block diagram of a system for establishingan electronic account for a customer;

[0023]FIG. 5B illustrates an embodiment of an identity validation (IDV)form consistent with the present invention;

[0024]FIG. 6 is a more detailed diagram of a system for establishing anelectronic account for a customer;

[0025]FIG. 7 is a block diagram of an application server consistent withthe present invention;

[0026]FIG. 8 depicts an embodiment of an electronic account numberconsistent with the present invention;

[0027]FIG. 9 is a flowchart of an address matching process performed bya registration system consistent with the present invention;

[0028]FIG. 10 is a block diagram of standardized address informationprocessed by an address matching engine consistent with the presentinvention;

[0029]FIG. 11A depicts an embodiment of the relationship between an ICRSdatabase and a master address database;

[0030]FIG. 11B depicts an alternative embodiment of the relationshipbetween an ICRS database and a master address database;

[0031]FIG. 11C depicts another alternative embodiment of therelationship between an ICRS database and a master address database;

[0032]FIG. 12 is a block diagram of a bulk mailing service using anInternet customer registration system consistent with the presentinvention;

[0033]FIG. 13 is a block diagram of services using a customerregistration system consistent with the present invention;

[0034]FIG. 14 is a block diagram of services that can be provided aspart of an electronic mailbox consistent with the present invention;

[0035]FIG. 15 is a block diagram of an advertisement filtering servicethat can be provided as part of an electronic mailbox consistent withthe present invention;

[0036]FIG. 16 is a block diagram of an e-mail service that can beprovided as part of an electronic mailbox consistent with the presentinvention;

[0037]FIG. 17 is a block diagram of an electronic postmark service thatcan be provided as part of an electronic mailbox consistent with thepresent invention;

[0038]FIG. 18 is a block diagram of a secure electronic mailbox that canbe provided as part of an electronic mailbox consistent with the presentinvention;

[0039] FIGS. 19A-19W are screen shots of a user interface for aregistration system consistent with the present invention;

[0040]FIG. 20 depicts some classes of messages that can be processed bya secure electronic mailbox;

[0041]FIG. 21 is a block diagram of a system for enabling a customer toapprove or disapprove electronic messages using a secure electronicmailbox;

[0042]FIG. 22 is a flowchart of secure electronic mailbox processingconsistent with the present invention;

[0043]FIG. 23 is a flowchart of a process for a customer to enroll in anelectronic bill presentment and payment system consistent with thepresent invention;

[0044]FIG. 24 is a flowchart of a process for a customer to activate anelectronic bill presentment and payment account consistent with thepresent invention;

[0045]FIG. 25 is a flowchart of a process for a biller to register foran electronic bill presentment and payment system consistent with thepresent invention;

[0046]FIG. 26 is a flowchart of a process for presenting bills to acustomer using the electronic account system;

[0047]FIG. 27 is a flowchart of bill delivery notification consistentwith the present invention;

[0048]FIG. 28 is a flowchart of an embodiment in which the EBPP systemstores bill summaries and bill details;

[0049]FIG. 29 is a flowchart of an embodiment in which the biller storesbill details;

[0050]FIG. 30 is a flowchart of an embodiment in which an EBPP system isprovided by a third party and offered to the payer via the electronicaccount system;

[0051]FIG. 31 is a flowchart for processing an electronic paymentconsistent with conventional systems;

[0052]FIG. 32 is a flowchart of one embodiment of a method forprocessing an electronic bill payment method using the presentinvention;

[0053]FIG. 33 is a flowchart of another embodiment of an electronic billpayment method consistent with the present invention;

[0054]FIG. 34 illustrates additional services that can be providedthrough an electronic account consistent with the present invention;

[0055]FIG. 35 is a block diagram of a system for providing a certificateauthority for proofing identities consistent with the present invention;

[0056]FIG. 36 is a block diagram of a digital certificate consistentwith the present invention;

[0057]FIG. 37 is a block diagram of a certificate authority consistentwith the present invention;

[0058]FIG. 38 is a block diagram of a proofing server consistent withthe present invention; and

[0059]FIG. 39 is a block diagram of a proofing workstation consistentwith the present invention.

V. DETAILED DESCRIPTION

[0060] A. Introduction

[0061] Systems and methods consistent with the present invention providean electronic account for a customer on a network, where the customer'selectronic address is linked to the customer's physical address. As witha conventional electronic account, a customer is able to send andreceive e-mail as well as conduct electronic transactions. Additionally,an electronic account consistent with the present invention ensuresflexible and secure communications by linking a customer's electronicaddress to the customer's physical address.

[0062] Embodiments described herein include systems and methods forproviding an electronic account to a customer, linking a customer'selectronic address to a physical address of the customer, establishingan electronic account using an Internet Customer Registration System,providing a secure electronic mailbox, and providing a certificateauthority for proofing identities.

[0063] B. Providing an Electronic Account to a Customer

[0064]FIG. 1 is a high level block diagram of a system for providing anelectronic account to a customer. A customer 100 can use a computer,e.g., a personal computer, to log onto a network 102, such as theInternet, to establish an electronic account 104. Electronic account 104enables customer 100 to access a wealth of electronic services,including e-mail and electronic transactions. These services can be bothsecure and non-secure and can be provided by any service provider, suchas an online merchant, a government agency, or a bank.

[0065] When electronic account 104 is established, it is linked to aphysical address of customer 100. Typically, the physical addresscorresponds to a location where the user receives physical mail, such asvia the USPS or other entity. In this way, anyone who receives mail at aphysical address can establish an electronic account consistent with thepresent invention. The physical address can be a home address, PostOffice box, business address, etc. Electronic account 104 can alsoinclude an electronic address, such as an e-mail address, for customer100.

[0066] To provide electronic services to customer 100, a serviceprovider can communicate with customer 100 via electronic account 104.If electronic account 104 is linked to customer 100's physical addressand e-mail address, the service provider can send a communication toelectronic account 104 and request delivery to either the physicaladdress or the e-mail address, or both. If such a communication directedto customer 100 contains an incomplete address, the complete address canbe determined using electronic account 104. As an added service, thesender, i.e., the service provider, could be informed of the completeaddress as part of an address correction service.

[0067] Electronic account 104 can allow customer 100 to receive anelectronic message in physical form at a physical address. In this way,the present invention makes e-mail available even to people withoutregular access to a computer. For example, a customer could use a publiccomputer, e.g., at a public library, to establish an electronic accountand obtain a vanity e-mail address. Thereafter, any messages sent to thee-mail address would be received at the electronic account and could beprinted and delivered to the physical address linked to the electronicaccount. The USPS or another company could offer this service to helpbridge the technology gap.

[0068] Customer 100 can also link a temporary address, either physicalor electronic, to electronic account 104 to request that messages bedelivered to the temporary address for a given period of time. Forexample, a businessman might have an electronic account with preferrede-mail and physical addresses at his office. When he takes a two-weekbusiness trip, he can use his electronic account to have his messagesdelivered to a new, temporary address, such as a cellular phone or acomputer in a hotel. Service providers sending the messages to thebusinessman would not need to know about his temporary address. Allcommunications would still be directed to the electronic account.

[0069] C. Linking an Electronic Address to a Physical Address of aCustomer

[0070]FIG. 2 is a high level block diagram of a system for linking anelectronic address to a physical address of a customer. Systemsconsistent with the present invention provide a link 204 between acustomer's electronic account 104 and a physical address 202 of thecustomer. Link 202 can provide added security to protect the customer'sprivacy, for example, by leveraging a trusted third-party resource suchas the USPS master address database.

[0071]FIG. 3 depicts one embodiment of a link between an electronicaddress and a physical address of a customer. Link 204 can beimplemented using an electronic account number 302 that corresponds toelectronic account 104. Electronic account number 302 can be generatedwhen electronic account 104 is created. Electronic account number 302can be linked to a customer's electronic address 304, e.g., a vanitye-mail address, and the customer's physical address 306. The electronicaddress could also be, for example, a facsimile number or telephonenumber. In one embodiment, a customer can choose the construction ofvanity e-mail address 304 (e.g., joesmith@usps.gov). Physical address306 is typically where the customer receives mail. For example, physicaladdress 306 can be the customer's residence expressed as ‘123 MainStreet, Memphis, Tenn. 38118.’ Consistent with the present invention,the customer can provide the physical address to be linked to theelectronic account, so a customer could select a home address or a workaddress, for example.

[0072] When the customer provides the physical address, the electronicaccount system can submit it to an address matching engine thatcommunicates with an address database. The address matching enginesubmits the address as a query to the address database, which returns astandardized physical address to be linked to the electronic account. Inone embodiment, the standardized physical address conforms to apre-approved format and includes a nine-digit ZIP code. In this way, thephysical address linked to the electronic account is as complete andcorrect as possible, even if the customer submitted only a partialaddress (e.g., only a 5-digit ZIP code). This address matching processis described in detail below with reference to FIG. 9.

[0073]FIG. 4 is a high level block diagram of a system for providingservices to a customer using an electronic account consistent with thepresent invention. An electronic account 402 for a customer links anelectronic address, e.g., a vanity e-mail address, an electronic accountnumber, and a physical address of the customer. Electronic account 402communicates with a plurality of services 404 via a network 406. Network406 can be, for example, the Internet. Using electronic account 402,services 404 can create physical messages to be sent to the customer'sphysical address as well as electronic messages to be sent to thecustomer's electronic address. As depicted in FIG. 4, services 404communicate with electronic account 402, and therefore do not need toknow the customer's electronic address or physical address. This enablesthe customer to take advantage of electronic services while protectingthe customer's privacy.

[0074] A service 404 can leverage the electronic account to send amessage to a plurality of customers. For example, a marketing firm couldsubmit a physical mailpiece, e.g., a brochure, to the electronic accountsystem along with a mailing list of physical addresses for a group ofcustomers having electronic accounts. The electronic account system cancreate a mailing list of e-mail addresses corresponding to the physicaladdresses using each customer's electronic account. The mailpiece can bescanned or otherwise converted into electronic format and delivered tothe customers' e-mail addresses. Alternatively, the message could bedelivered to a different electronic address, such as a facsimile numberor telephone number. This type of service is described below withreference to FIG. 12.

[0075] D. Establishing an Electronic Account using an Internet CustomerRegistration System (ICRS)

[0076] 1. Customer Registration Process

[0077]FIG. 5A is a high level block diagram of a system for establishingan electronic account for a customer. A customer 502 at a computer, suchas a personal computer, connects to a network 504 to provideregistration information to a registration system 506. Network 504 canbe, for example, the Internet, and registration system 506 can be, forexample, the USPS Internet Customer Registration System. Theregistration information can include customer name, physical address,e-mail address, telephone number, a public key or other password, and arequest for a personal or business electronic account.

[0078] After customer 502 provides registration information toregistration system 506, a mailpiece 508, such as a confirmation letter,is created and sent to the user at a physical address. The physicaladdress can be one provided by the customer with the registrationinformation. Mailpiece 508 contains an identity validation (IDV) form510, described with regard to FIG. 5B below. To complete theregistration process, customer 502 takes IDV form 510 to a registrationoffice, such as a local Post Office. There, a clerk verifies thecustomer's identity and uses IDV form 510 to send identificationverification information to registration system 506.

[0079]FIG. 5B illustrates an embodiment of an identity validation (IDV)form consistent with the present invention. As described above,mailpiece 508 containing IDV form 510 is sent to the customer byregistration system 506. When the customer takes IDV form 510 to anidentity proofing location, e.g., a local Post Office, a clerk validatesthe customer's identity and transmits a confirmation to registrationsystem 506.

[0080] As shown in FIG. 5B, IDV form 510 can include the customer'sphysical address, the customer's e-mail address, the location of thenearest registration office, and a date by which the customer must go tothe registration office. IDV form 510 can also include a list ofidentity validation documents that the customer must present at theregistration office, such as a driver's license, birth certificate, orutility bill. In one embodiment, the customer can select the identityvalidation documents when submitting registration information toregistration system 506.

[0081] IDV form 510 can include a confirmation bar code. Theconfirmation bar code can be created by the registration system 506 andlinked to the electronic account when IDV form 510 is created. Once aclerk validates the customer's identity, for example, by examining theidentity validation documents, the clerk can scan the confirmation barcode and send it electronically to registration system 506. Whenregistration system 506 receives the scanned confirmation bar code, thecustomer's electronic account can be activated. Activation can occur,for example, by sending a digital certificate, password, or othernotification to the customer.

[0082] In one embodiment of the present invention, two copies of IDVform 510 are sent to the customer: one copy for the customer to take tothe registration office and another copy for the customer to retain forhis records. IDV form 510 can include a set of instructions and acustomer care telephone number that the customer can call if he has anyproblems. IDV form 510 can also include a signature and date block forthe customer to execute as part of the identification validation processat the registration office.

[0083]FIG. 6 is a more detailed diagram of a system for establishing anelectronic account for a customer. As described above, customer 502provides registration information to registration system 506 via network504. Registration system 506 includes an application server 602, a webserver 604, and a database server 606. Application server 602 includessoftware tools to generate dynamic content and execute applications forregistration system 506. Application server 602 is described in moredetail below with reference to FIG. 7. Web server 604 processes HTMLrequests to enable communications with customer 502 and to provide datato application server 602 and database server 606.

[0084] Database server 606 processes all communications with an InternetCustomer Registration System (ICRS) database 608. In one embodiment,ICRS database 608 consists of two logical components: a customer namedatabase 610 and a customer address database 612. Customer name database610 stores the registration information provided by a customer alongwith an electronic account number assigned to the customer. Customeraddress database 612 stores the customer's physical address. In thisembodiment, the physical address is stored separately from thecustomer's name and other information to protect the security of thecustomer. To create a high level of security, packet filter access canbe installed between customer name database 610 and customer addressdatabase 612. Consistent with the present invention, the ICRS databasecould be maintained as a single database.

[0085] When registration system 506 receives registration informationfrom customer 502, it stores the registration information in ICRSdatabase 608 as described above. An identification verification (IDV)form generator 614 then extracts data from ICRS database 608 and passesthe data to a print and insertion function 616 that generates mailpiece508 containing IDV form 510. Alternatively, IDV form generator 614 andprint and insertion function 616 can be a single process. In oneembodiment, the IDV form and mailpiece are generated within 24 hoursafter the customer's registration information is stored in ICRS database608.

[0086] As described above, customer 502 takes IDV form 510 to aregistration office where a clerk verifies, or “proofs,” the customer'sidentity. The identity proofing can include comparing a photo ID to thecustomer in person. When the customer's identity is successfullyproofed, the clerk scans a confirmation bar code from IDV form 510 andtransmits the scanned bar code to registration system 506 via a deliveryconfirmation host 618. In one embodiment, IDV form generator 614 cansend a notification to delivery confirmation host 618 when IDV form 510is created. When this notification is received, delivery confirmationhost 618 can communicate with application server 602 to provide noticethat identification verification information is soon to be received.When the scanned bar code is sent to delivery confirmation host 618,application server 602 retrieves this identification verificationinformation from delivery confirmation host 618.

[0087] Once the identification verification information is received byapplication server 602, a request is generated and sent to a digitalcertificate authority 620, such as, for example, the CertificateAuthority (CA) described below with reference to FIG. 35. The requestcan direct digital certificate authority 620 to generate a digitalcertificate for customer 502. The request can include, for example, apublic key and information provided by customer 502 during theregistration process.

[0088] A digital certificate is a well-known tool for sending securemessages. A CA issues an encrypted digital certificate containing acustomer's public key and a variety of other identification information.The Certificate Authority makes its own public key available throughprint or perhaps on the Internet. The recipient of an encrypted messageuses the CA's public key to decode the digital certificate attached tothe message, verifies the digital certificate as issued by the CA, andthen obtains the sender's public key and identification information heldwithin the certificate. With this information, the recipient can send anencrypted reply.

[0089]FIG. 7 is a block diagram of an application server consistent withthe present invention. Application server 602 includes applicationserver software 702, certificate software 704, and address matchingengine delivery point/plus 4 (AME DP/+4) system software 706.Application server software 602 processes logic and instructions tosupport registration system 506. Application server software 702 alsoincludes account number generator software 708 that generates anelectronic account number for a customer. In one embodiment, accountnumber generator software 708 is embedded into application serversoftware 702 in the form of a dynamically loadable library so that itbecomes part of application server software 702 at run time. In anotherembodiment, account number generator software 708, can be stand-alonesoftware for generating account numbers. The electronic account numberis described in detail below with reference to FIG. 8.

[0090] Certificate software 704 is an application programming interface(API)—a tool enabling one piece of software to communicate with anotherpiece of software. Certificate software 704 is used by registrationsystem 506 to construct and submit requests to digital certificateauthority 620 and to retrieve a customer's digital certificate fromdigital certificate authority 620.

[0091] AME DP/+4 system software 706 includes an interface to addressmatching directories and associated software to access thosedirectories. This software can be used to resolve a physical addressbased on USPS delivery guidelines to create a standardized physicaladdress. In one embodiment, a standardized physical address can meet oneof four levels of address standardization. The first level ofstandardization is ‘delivery point,’ which resolves the address to anunique delivery point. The second level of standardization is ‘plus 4,’which resolves the address to a valid range of addresses within a plus 4segment of a ZIP code. The third level of standardization is ‘5 digit,’which resolves the address to a five-digit ZIP code area only. Thefourth level of standardization is ‘last line,’ which resolves theaddress to a city, state, and ZIP code. The address matching process isdescribed in more detail below with reference to FIG. 9.

[0092]FIG. 8 depicts an embodiment of an electronic account numberconsistent with the present invention. In one embodiment, account numbergenerator software 708 generates a unique electronic account number 802consisting of ten alphabetical and numeric characters and one checkdigit, such as a modulus low end check digit. In this embodiment, amongthe ten alphabetical and numeric characters, no more than threealphabetical characters can be strung together to prevent havingprofanity inserted into the electronic account number.

[0093]FIG. 8 depicts six exemplary formats for an electronic accountnumber. Consistent with the present invention, any other formatproviding a unique identifier can be used, including formats with feweror more than ten characters. The electronic account number can be storedin customer name database 610 and used to link the customer's name andother information to the customer's physical address.

[0094] 2. Address Matching Process

[0095]FIG. 9 is a flowchart of an address matching process performed bya registration system consistent with the present invention. A physicaladdress is received by AME DP/+4 software 706 and is passed to anaddress matching engine 904. For instance, the address can be receivedfrom a customer via Web server 604. Address matching engine 904processes the physical address to create a query 906 and sends query 906to an address matching directory (AMD) database 908. Query 906 is usedto retrieve a standardized address stored in AMD database 908.Standardized address information 910 can include the standardizedaddress and/or a corresponding delivery point identification (DPID) keythat points to the location in AMD database 908 where the standardizedaddress can be found. Standardized address information 910 is passedback to address matching engine 904, where it can be sent to ICRSdatabase 608. If a DPID key cannot be determined via the addressmatching engine process, a flag can be set to send feedback to anaddress management office or other service personnel.

[0096]FIG. 10 is a block diagram of standardized address informationprocessed by an address matching engine consistent with the presentinvention. Standardized address information 910 can include astandardized address and related information, including a DPID key. TheDPID key can be used to access a storage location in a master addressdatabase as described below. The DPID key can be stored with theelectronic account information in ICRS database 608.

[0097]FIG. 11A depicts an embodiment of the relationship between an ICRSdatabase and a master address database. ICRS database 608 can store aDPID key with a customer's electronic account information. To obtainupdated address information, ICRS database 608 can use DPID key 1102 toaccess master address database 1104 and obtain the address 1106corresponding to DPID key 1102. In this way, an electronic accountsystem consistent with the present invention can perform periodicaddress updates and quality control processes on ICRS database 608.Using the DPID key in this embodiment keeps ICRS database 608 up-do-datewith having to perform multiple address matching engine processes (asdescribed in FIG. 9).

[0098]FIG. 11B depicts an alternative embodiment of the relationshipbetween an ICRS database and a master address database. If ICRS database608 does not store a DPID key with a customer's electronic accountinformation, it can obtain one by submitting a physical address 1108 toa static monolithic address database 1110. Static monolithic addressdatabase 1110 can then use an address matching engine (as described inFIG. 9) to obtain a DPID key 1112 from master address database 1104.DPID key 1112 is then returned to ICRS database 608.

[0099]FIG. 11C depicts another alternative embodiment of therelationship between an ICRS database and a master address database. IfICRS database 608 does not store a DPID key with a customer's electronicaccount information, it can send a physical address 1114 directly tomaster address database 1104. DPID key 1116 is then returned to ICRSdatabase 608.

[0100] 3. Services Based on Internet Customer Registration System

[0101]FIG. 12 is a block diagram of a bulk mailing service using anInternet customer registration system consistent with the presentinvention. As described above, customer 502 uses a computer to accessregistration system 506 via network 504. Registration system 506includes ICRS database 608, which can be accessed by an e-mailboxrepository 1210 to provide e-mail services to customer 502. A senderwishing to communicate with a plurality of customers having electronicaccounts can submit a file 1202 containing a physical address file and acontent file. The physical address file can be, for example, a mailinglist, and the content file can be, for example, an advertisement.

[0102] The physical address file is processed in an address matchingsystem 1204 as described above to obtain standardized physical addressesfor the customers. The standardized physical addresses are processed bya key generator 1206 to obtain keys for accessing ICRS database 608.Using keys created by key generator 1206, ICRS database 608 is queriedat 1208 to create an e-mail address mailing list 1210 corresponding tothe physical address file. The content file is combined with e-mailaddress mailing list 1210 to facilitate an electronic mailing 1212.Electronic mailing 1212 is sent to an e-mail routing system 1214 thatsends electronic mailing 1212 to e-mailbox repository 1216 for deliveryto the plurality of customers. E-mail routing system 1214 may alsoprovide a status report of e-mail delivery to the sender that providedfile 1202.

[0103]FIG. 13 is a block diagram of services using a customerregistration system consistent with the present invention. Electronicaccount 104 and registration system 506 can enable customers to accessan electronic mailbox (or e-mailbox) service 1302 and other services1304 such as mailing online, electronic bill presentment and payment,etc. Electronic mailbox services 1302 can include a secure electronicmailbox, described in more detail below.

[0104]FIG. 14 is a block diagram of services that can be provided aspart of an electronic mailbox consistent with the present invention.E-mailbox service 1302 can receive and store different types ofmessages, including advertisement messages 1402, e-mail messages 1404,electronic postmark (EPM) messages 1406, and secure electronic mailbox(SEM) messages 1408. Other types of messages could also be received andstored consistent with the present invention. In one embodiment, sometypes of messages, such as EPM messages and SEM messages can be accessedonly via a password or a digital certificate key. In this way, thecustomer can select different levels of security for different types ofmessages.

[0105]FIG. 15 is a block diagram of an advertisement filtering servicethat can be provided as part of an electronic mailbox consistent withthe present invention. Advertisement messages 1402 could be filteredaccording to the customer's preferences. A customer could specifycertain types or categories of advertisement messages to be accepted bythe e-mailbox. For example, a customer may wish to receive advertisementmessages from automobile companies but no others or to receive noadvertisements at all.

[0106]FIG. 16 is a block diagram of an e-mail service that can beprovided as part of an electronic mailbox consistent with the presentinvention. Conventional e-mail messages can be received and stored ine-mail message section 1404 of e-mailbox 1302. E-mail message section1404 can include an in-box, out-box, and trash section as found inconventional e-mail systems.

[0107]FIG. 17 is a block diagram of an electronic postmark service thatcan be provided as part of an electronic mailbox consistent with thepresent invention. An electronic postmark service is described in U.S.patent application Ser. No. 09/675,677 entitled Systems and Methods forAuthenticating an Electronic Message, filed on Sep. 29, 2000 andincorporated herein by reference.

[0108]FIG. 18 is a block diagram of a secure electronic mailbox that canbe provided as part of an electronic mailbox consistent with the presentinvention. The secure electronic mailbox service is described in moredetail below with reference to FIG. 20.

[0109] 4. User Interfaces for Internet Customer Registration System

[0110] FIGS. 19A-19W are screen shots of a user interface for aregistration system consistent with the present invention. These screenshots can be, for example, HTML documents stored in registration system506 and presented by web server 604 to customer 502 at a computerrunning a browser. Although these user interfaces describe theregistration and activation processes in terms of a secure electronicmailbox, these processes can also be used to establish an electronicaccount consistent with the present invention.

[0111]FIG. 19A includes an overview of a secure electronic mailbox asprovided by the USPS consistent with the present invention. Although thefigures describe an electronic account system provided by the USPS, thepresent invention could be practiced by a non-USPS entity withoutdeparting from the spirit and scope of the invention. FIGS. 19B and 19Ccontain instructions to the customer for establishing an electronicaccount using registration system 506. FIGS. 19D-19F contain a sampleprivacy and certification policy for use with an electronic accountsystem.

[0112]FIG. 19G is a user interface for collecting registrationinformation from a customer consistent with the present invention. Theuser interface shown has two sections: individual information and e-mailaddress selection. The individual information section provides textboxes and/or drop-down lists for the customer to enter: full name,including first name, middle initial, and last name; title, such as Mr.or Miss; suffix title, such as Jr., Sr., II or Ill; date of birth,including month, day, and year; home phone; and work phone. The e-mailaddress selection section includes text boxes and/or drop-down lists forthe customer to enter a first, second, and third choice of a vanitye-mail address along with a password for the e-mailbox. The userinterface asks the customer to reenter the password to ensure that it isaccurately captured. This section also enables the customer to choose ashared secret, which can consist of an adjective, a noun, and a verb.The shared secret can serve as a master password for the registrationsystem and helps to identify the customer in the future. For example,the shared secret can be used by the customer to gain access to thecustomer's digital certificate later in the registration process.

[0113]FIG. 19H is a user interface that is displayed to the customer ifthe vanity e-mail address selected is unavailable. The user interfacecan offer suggestions of available e-mail addresses and a text box toreceive the customer's alternate selection.

[0114]FIG. 191 is a user interface for obtaining physical addressinformation from the customer. The user interface provides text boxesand/or drop-down lists for the user to input a residential address,including: address type, house number, street name, apartment/suiteidentifier and number, city, state, and ZIP code. A set of “radiobuttons” is also provided for the customer to indicate whether themailing address (i.e., physical address) is the same as the residentialaddress. The address type field can be used to trigger data capturetools, such as a set of templates for various address types, includingPost Office box address, street address, etc.

[0115]FIG. 19J is a user interface for obtaining identity validationinformation from the customer. The customer is prompted to select twoforms of identification to be used in the identification verificationprocess. A drop-down list of acceptable identification documents ispresented. The acceptable identification documents can include a photoidentification, e.g., driver's license, passport, military ID, etc., anda secondary ID, e.g., utility bill, telephone bill, etc. Based on thetype of identification document that the customer selects, differentdata can be captured, including a control number, expiration date, etc.

[0116]FIG. 19K is a user interface for displaying registrationinformation to the customer. This user interface displays theinformation that has been provided by the customer and enables thecustomer to edit the information if needed and to print the informationto retain for his records before proceeding with the rest of theregistration process. In one embodiment, the physical address that ispresented has been processed by the address matching system describedabove. In other words, the standardized physical address is presented.In this embodiment, if the address matching system could not resolve thephysical address to a delivery point or plus 4 level, asterisks and amessage can be displayed to inform the customer that the physicaladdress is not fully resolved.

[0117]FIG. 19L is a user interface for explaining a private key systemto the customer. The private key is to be generated by browser softwarerunning on the customer's computer at the direction of the registrationsystem. The private key will be used by the customer to access thedigital certificate to activate the customer's electronic account. Theuser interface presents a drop-down list for the customer to select anencryption strength, if the customer's browser supports different levelsof encryption.

[0118]FIG. 19M is a user interface for generating a private key for thecustomer. This user interface enables the customer to click ‘okay’ tocontinue with the private key process or to click ‘cancel’ to stop.

[0119]FIG. 19N is a user interface for establishing a password for thecustomer's private key. Because the private key will enable access tothe customer's digital certificate, and therefore the electronicaccount, the customer is encouraged to establish a password to protectthe private key. This user interface enables the customer to select apassword and enter a confirmation copy of the password beforecontinuing.

[0120]FIG. 19O is a user interface presented to a customer declining toestablish a password for the private key. This user interface informsthe customer that a password can be established at a later time andenables the customer to continue the registration process withoutestablishing a password for the private key.

[0121]FIG. 19P is a user interface for instructing the customer aboutthe in-person identity validation process. Once the online applicationprocess, or registration process, is complete, a temporary or inactivestatus is assigned to the customer's electronic account. This userinterface displays a date on which an identity validation form will bemailed to the customer and explains that the customer will need to takethe identity validation form and the chosen identification documents toa registration office to complete the in-person identity validationprocess.

[0122]FIG. 19Q is a user interface for beginning the activation processfor the customer's electronic account. Once the customer completes thein-person identity validation process, the customer can activate theelectronic account. To begin the activation phase, the customer can usethis user interface to enter the vanity e-mail address.

[0123]FIG. 19R is a user interface for capturing the customer's sharedsecret to activate the customer's electronic account. The customer isprompted to enter the shared secret selected during the onlineregistration process.

[0124]FIG. 19S is a user interface for accepting a certificationpractice statement. A certification practice statement is a statement ofrules and regulations governing the use of a digital certificate. Oncethe customer has read the statement, he can click the ‘accept’ button tocontinue or the ‘quit’ button to stop.

[0125]FIG. 19T is a user interface for presenting a digital certificateto the customer. This user interface displays a name for the digitalcertificate and enables the customer to provide a different name, ifdesired.

[0126]FIG. 19U is a user interface for saving the digital certificate.The user interface explains the importance of saving a copy of thedigital certificate and enables the customer to save it in a safelocation or on a floppy disk, for example. The digital certificate canbe downloaded into the customer's browser, onto a Smart Card, or onto adigital certificate holding device.

[0127]FIG. 19V is a user interface for activating the electronicaccount. Once the customer has received the digital certificate, thisuser interface enables the customer to confirm that the digitalcertificate has been installed properly on his computer. A customer carephone number is displayed in case the customer has any problems.

[0128]FIG. 19W is a user interface for completing the electronic accountregistration process. This user interface displays a message informingthe customer that the electronic account has been activated.

[0129] E. Providing a Secure Electronic Mailbox

[0130] 1. Overview of Secure Electronic Mailbox

[0131] One of the services available through an electronic accountconsistent with the present invention is a secure electronic mailbox(SEM). The SEM can be provided as part of an e-mailbox linked to theelectronic account as described above. Electronic messages can be sentto a customer using the SEM. Unlike a conventional electronic mailbox,the SEM can provide a number of services in addition to receiving anddisplaying electronic messages. For example, the SEM can enablefiltering of messages, notification when a message is received and/orviewed, and electronic bill presentment and payment. The SEM can offervarious levels of security using, for example, message authentication,time and date seals, and digital certificates.

[0132]FIG. 20 depicts some classes of messages that can be processed bya secure electronic mailbox (SEM). SEM 2002 can process a bill, such asa mortgage bill, utility bill, etc. from a biller 2004, i.e., a biller,a biller's representative, or a biller service provider. SEM 2002 canprocess bills from a plurality of bill consolidators 2006 and 2008. SEM2002 can also process legal communications and legal documents 2008,such as patent applications, wills, etc. Other documents 2010 can alsobe processed by SEM 2002. In one embodiment of the present invention,all of a customer's bills (regardless of their source) are consolidatedand presented to the user with a single user interface, or bill manager.Similarly, payment options can be consolidated and presented to the userwith a single user interface, or payment manager. In this embodiment, acustomer can manage all of his bills in one, seamless interface, withouthaving to know the source of the bills.

[0133]FIG. 21 is a block diagram of a system for enabling a customer toapprove or disapprove electronic messages using a secure electronicmailbox. When SEM 2002 receives SEM input 2102, such as an electronicbill or advertisement, SEM input 2102 can be stored in an SEM database2104, as described below. By accessing SEM database 2104, a customer canview SEM input 2102 and approve or disapprove it 2106. For example, ifSEM input 2102 is an electronic bill, approval might indicate that thebill should be paid using the electronic account and disapproval mightindicate that the bill should not be paid. The customer communicatesapproval or disapproval 2106 to SEM database 2104, which in turn reportsthe customer's decision as SEM output 2108. SEM 2002 thus enables acustomer to interact with senders of electronic messages indirectly,adding security and privacy protections.

[0134] 2. Detailed Description of Secure Electronic Mailbox

[0135]FIG. 22 is a flowchart of secure electronic mailbox processingconsistent with the present invention. A customer can connect to secureelectronic mailbox 2002 via a website, e.g. usps.com, or other portal ona network (step 2202). If the customer does not have a mailbox, i.e., aSEM, (step 2204), then the customer will be prompted to register for anelectronic account and an SEM (step 2206). The customer can then performthe registration process described above to establish an electronicaccount and SEM (step 2208).

[0136] If the customer has a mailbox (step 2204), the customer isprompted to login to the mailbox (step 2210) to give the customer accessto SEM services. As part of the login process, the customer isauthenticated by the electronic account system using, for example, adigital certificate or private key (step 2212). An embodiment of acertificate authority for performing this authentication is described inmore detail below.

[0137] If this is the customer's initial login (step 2212), i.e., thefirst time the customer has accessed the mailbox, the customer isprompted to set up a profile (step 2214). The profile is linked to thecustomer's mailbox and can indicate the services the customer would liketo access and other profile menu options (step 2216). The profile menuoptions can include screen appearance, such as background color ortoolbars, and other options as appropriate.

[0138] If this is not the customer's initial login, and if the customerwas successfully authenticated, then the customer is given access to themailbox and the customer is prompted to select an SEM service (step2218). Here the customer can select one of the different types ofservices available through the customer's electronic account and SEMincluding: EPM mail, Internet mail, advertisements, bill payment, forms,government services, etc.

[0139] The different services can be provided using, for example,different storage folders within the SEM. The customer can select an EPMmail folder (step 2220) that contains mail having an electronic postmark(EPM). The customer can select an Internet mail folder (step 2222) thatcontains Internet mail and may or may not include security. Anadvertisement, or ads, folder that contains advertisements can be chosen(step 2224). The advertisements can be, for example, targetedadvertisements sent by an advertiser. The advertisements may befiltered, as described above with reference to FIG. 15.

[0140] The customer can select a bills folder (step 2226) that containsbills from billers and/or bill consolidators that participate in anelectronic bill presentment and payment (EBPP) system via the SEM. Thecustomer can select a forms folder (step 2228) containing electronicforms from companies and/or government agencies, such as tax forms ordriver's license renewal forms. The customer can select a folder ofgovernment services (step 2230) containing, for example, links togovernment sites such as the Internal Revenue Service. The customer canalso access other services (step 2232) consistent with the presentinvention.

[0141] When the customer selects either Internet mail (step 2222) orcertified mail (step 2220), the customer has a selection of actions tochoose from. The customer can choose to create mail (i.e., an electronicmessage) (step 2234). As part of the mail creation process, the customermay add attachments to the mail or use a spell-checking program. Thecustomer can choose to forward mail (step 2236) or reply to the senderof a message (step 2238). The customer can also choose to view a message(step 2240). This action allows the customer to view the contents of amessage and open or save attachments. If the customer chooses to createmail (step 2234), forward mail (step 2236), or reply to mail (step2238), the customer is prompted to address the mail (step 2242) byselecting a name from an address book or otherwise providing an addressfor the message. The sender can use the secure electronic mailbox tosend a message to a recipient at a physical and/or electronic address.Once the message is addressed (i.e., to either a physical or anelectronic address), the user can send the message (step 2244).

[0142] To send the message, the customer can select delivery options(step 2246), including options such as “delivery notification” or“electronic delivery.” If the addressee of the message has an electronicaccount, the customer can choose “physical delivery” and the messagewill be printed and delivered in physical form to the addressee'sphysical address. In addition to delivery options, the customer canselect a priority (step 2248) such as “high priority” or “urgent.” Thecustomer can choose to postmark the message with an EPM. The customercan also choose to encrypt the message (step 2250) before it is sent.This allows the customer to encrypt a message for privacy and to preventa third party intercepting the message from reading it. The user canchoose to sign the message (step 2252), for example, by attaching adigital signature to the message. Then, the message is sent (step 2253).

[0143] If the customer chooses to view a message (step 2240), thecustomer can select a service to detect tampering (step 2254). Thisallows the customer to verify whether a message has been tampered withsince it was signed by the sender. The tampering detection process canaccess a secure time and date seal function (step 2256) such as anelectronic postmark (EPM) system as described in U.S. patent applicationSer. No. 09/675,677, entitled Systems and Methods for Authenticating anElectronic Message, filed on Sep. 29, 2000. The customer can also chooseto apply a time and date seal (e.g., an EPM) to all inbound messages(step 2258). This option will direct the SEM to automatically attach atime and date seal (e.g., an EPM) to a message when it is received bythe SEM. The customer can have the option to use the time and date seal(e.g., the EPM) as a filter for received mail, for example by settingthis as a profile menu option (step 2216).

[0144] Several components of the electronic account system can be usedto perform the tasks depicted in FIG. 22. A Create and Activate Mailboxcomponent 2208 contains a registration system such as the InternetCustomer Registration System described above. Create and ActivateMailbox component 2208 can automatically create a mailbox once thecustomer has completed the online registration process. The mailbox canbe created, for example, by designating an electronic storage locationfor the customer. In one embodiment, the mailbox will remain inactiveuntil identification verification is performed as described above. AProfile Management component 2260 can be used to manage the profileinformation of the customer. This profile information and profile menuoptions can be stored in a configuration database 2262.

[0145] A Mail Management component 2264 can manage messages received bythe SEM and allow customers to retrieve, view, save, archive and sortmessages. Mail Database 2266 is a storage location for the messages ofthe SEM. An eAddress Management component 2268 manages a customer'selectronic address books, which can be stored in an Address Database2270. An electronic postmark (EPM) system 2256 can be used to enable thecustomer to attach a time and date seal (e.g., an EPM) to a message andto detect when a message with a time and date seal (e.g., an EPM) hasbeen tampered with. A Sign and Encrypt component 2272 can be used toenable a customer to digitally sign messages.

[0146] 3. Electronic Bill Presentment and Payment

[0147] A secure electronic mailbox consistent with the present inventionsupports many services in addition to electronic message handling. Acustomer with an electronic account can use an electronic billpresentment and payment (EBPP) service to receive and pay billselectronically. Billers, such as utility companies or credit cardcompanies, can join the EBPP system and submit bills, bill summaries,bill histories, etc. to the customer (i.e., the payer) using theelectronic account and SEM systems. An EBPP system consistent with thepresent invention improves upon conventional electronic bill paymentsystems in several ways. First, the present invention uses an EBPPsystem to improve communication and feedback between a biller and apayer. Second, an EBPP system consistent with the present invention islinked to a physical address of the payer enabling flexiblecommunications including physical and electronic mail. Third, because anEBPP system consistent with the present invention is linked to a payer'selectronic account, the biller knows that the identity of the payer wasverified in person and therefore can be more confident in sending billsand receiving payment via the EBPP system. Fourth, bills from severalsources can be consolidated for viewing seamlessly, i.e., withoutindicating the source of the bill. Payment can be provided to theappropriate biller seamlessly, i.e., without indicating the paymentdestination to the customer.

[0148]FIG. 23 is a flowchart of a process for a customer to enroll in anelectronic bill presentment and payment system consistent with thepresent invention. A payer having an electronic account can send amessage requesting enrollment in an electronic bill presentment andpayment (EBPP) system (step 2302). The enrollment request can be sent toa secure electronic mailbox (SEM) system consistent with the presentinvention. If the enrollment request includes a reference to a bankaccount of the customer, then the EPBB system can access that bankaccount to automatically pay bills for the payer. The SEM systemauthenticates the payer using, for example, the digital certificate fromthe payer's electronic account (step 2304). The authentication processis described in more detail below. When the payer is authenticated, theSEM system retrieves information about the payer, for example, from thepayer's electronic account, and sends the enrollment request and payerinformation to an EBPP system (step 2306). In one embodiment, the EBPPsystem can send the enrollment request and payer information to a billerand receive an enrollment status from the biller. Once the EBPP systemestablishes and activates an EBPP account for the payer, the enrollmentstatus is sent from the EBPP system to the SEM system (step 2308) andthen to the payer (step 2310).

[0149] In an alternative embodiment, the enrollment request can also beinitiated by a biller. For example, a payer could sign up for the EBPPsystem at a biller's web site. The biller-initiated enrollment requestwould then be sent from the biller to the EBPP system (step 2312) andthe biller-initiated enrollment status can be returned to the biller(step 2314).

[0150]FIG. 24 is a flowchart of a process for a customer to activate anelectronic bill presentment and payment account consistent with thepresent invention. After the enrollment process, the payer can requestactivation of the EBPP account by sending an account activation requestto the SEM system (step 2402). Before processing the request, the SEMsystem can authenticate the user with a certificate authority asdescribed below (step 2404). Once the payer is authenticated, theaccount activation request is sent from the SEM system to the EBPPsystem along with information from the payers electronic account (step2406). The account activation request is then sent to a biller (step2408). When the biller activates the payer's account, a response is sentfrom the biller to the EBPP system (stem 2410). The EBPP system sendsthe account activation status to the SEM system (step 2412) and the SEMsystem sends it to the payer (2414). The biller could also send out aphysical notification of the account activation status directly to thepayer (step 2416). In an alternative embodiment, account activationcould be initiated by the biller and the biller can be notified of theaccount activation (step 2418).

[0151]FIG. 25 is a flowchart of a process for a biller to register foran electronic bill presentment and payment system consistent with thepresent invention. To register, a biller sends biller registrationinformation to the electronic bill presentment and payment (EBPP) system(step 2502). The EBPP system processes the biller registrationinformation and sends it through general administrative and marketingprocessing (step 2504). This step may include, for example, verifyingthe biller's taxpayer ID number or other identifier or evaluating thebiller's accounting software. Once the biller is registered, the EBPPsystem sends a registration completion notification to the biller (step2506). Marketing or advertisements can also be sent from the EBPP systemto the biller.

[0152]FIG. 26 is a flowchart of a process for presenting bills to acustomer using the electronic account system. In one embodiment, abiller can submit bill summaries for multiple customers to theelectronic account system (step 2602) via a network such as theInternet. Each bill summary may be marked with an EPM and can be storedin a SEM corresponding to a specific customer. When a customer logs intohis SEM (step 2604), the customer can view the bill summary (step 2606).The bill summary may be marked with an EPM. The customer can thenrequest, via the SEM system, to view bill details (step 2608). The billdetails may be marked with an EPM. The customer can also link directlywith the biller to exchange information or pay a bill (step 2610). Usingthe electronic account system, the customer can submit paymentinstructions, such as a bank account to be debited or a credit cardaccount to be charged. The electronic account system can notify thebiller when a customer has viewed the bill summary and/or bill detail.In an alternative embodiment, the customer can pay view paymentinformation via the SEM system and submit payment instructions directlyto the SEM.

[0153]FIG. 27 is a flowchart of bill delivery notification consistentwith the present invention. A biller can send bill information for apayer having an electronic account to an EBPP system (step 2702). Thebiller can also send other information for the payer, such asadvertisements. The EBPP system formats a bill using the billinformation and stores it in the payer's secure electronic mailbox (step2704). The formatted bill can include an EPM. The SEM can send anotification to the EBPP system when the bill is delivered, i.e., storedin the payer's SEM (step 2706). The SEM can send another notificationwhen the payer views the bill in the SEM. The EBPP system then sendsthese notifications to the biller (step 2708). In one embodiment, EBPPsystem can use the bill information from the biller to generate aphysical mail piece that is sent to the payer via U.S. mail (step 2710).The EBPP system can also use an electronic postmark (EPM) system toattach an EPM to the bill before it is stored in the payer's SEM (step2712).

[0154] There are many alternative embodiments for storing and presentingbill information to the payer. The electronic account system can storeall bill information in the EBPP system (e.g., to bill for SEMservices). Alternatively, the EBPP system may store only bill summaryinformation and the payer can communicate directly with a biller toobtain bill details. In another embodiment, the EBPP system may beprovided by a third party and offered to the payer via the electronicaccount system.

[0155]FIG. 28 is a flowchart of an embodiment in which the EBPP systemstores bill summaries and bill details. The payer can access his SEM toview bill summaries (step 2802) and to view bill details, historicalbills, and/or payment information (step 2804). When the payer accessesthe SEM, the payer will be authenticated using, for example, acertificate authority (step 2806). In this embodiment, the SEM obtainsbill detail (i.e., line by line bill details) and bill summaryinformation (e.g., overall balance due, biller identifier, etc.) fromthe EBPP system, stored within the electronic account system (steps2808, 2810). The payer can also obtain historical information such aspayment history and past bills.

[0156]FIG. 29 is a flowchart of an embodiment in which the biller storesbill details. The payer can access his SEM to view bill summaries (step2902), bill detail, historical bills and/or payment information (step2904). When the payer accesses the SEM, the customer will beauthenticated using, for example, a certificate authority (CA/PKI) (step2906). In this embodiment, the SEM obtains bill detail (i.e., line byline bill details) and bill summary information (e.g., overall balancedue, biller identifier, etc.) from the EBPP system (step 2908), which inturn obtains bill details from a remote biller, e.g., via a network.(step 2910). The payer can also obtain historical information such aspayment history and past bills.

[0157]FIG. 30 is a flowchart of an embodiment in which an EBPP system isprovided by a third party 3001 and offered to the payer via theelectronic account system. The payer can access his SEM to view billsummaries and bill detail (step 3002) and to view historical billsand/or payment information (step 3004). The bills may be issued by aplurality of billers, but the bills can be consolidated and presented tothe payer using a single, seamless user interface. When the payeraccesses the SEM, the customer will be authenticated using, for example,a certificate authority (step 3006). In this embodiment, the SEM obtainsbill detail (i.e., line by line bill details) and bill summaryinformation (e.g., overall balance due, biller identifier, etc.) from athird-party EBPP system (step 3008), which in turn obtains bill detailsfrom a remote biller, e.g., via a network. (step 3010). The payer alsocan also obtain historical information such as payment history and pastbills.

[0158]FIG. 31 is a flowchart for processing an electronic paymentconsistent with conventional systems. To pay a bill electronically, apayer sends payment authorization to a financial processor such as, forexample, Checkfree (step 3102). The financial processor sends thepayment authorization to the payer's bank (step 3104). The paymentauthorization can include a payer's bank account designation and abiller's bank account number. The payer's bank can send payment to thebiller's bank (step 3106), e.g., by electronically transferring money tothe biller's bank account. The payer's bank can then send a transactionconfirmation to the financial processor (step 3108). Alternatively, thefinancial processor can send payment directly to the biller's bank (step3110). The financial processor can send the transaction confirmation tothe payer (step 3112). Once payment is received, the biller's bank cansend payment notification to the payer (step 3114).

[0159]FIG. 32 is a flowchart of one embodiment of a method forprocessing an electronic bill payment method using the presentinvention. A payer sends payment authorization to his SEM (step 3202).The SEM can apply an electronic postmark (EPM) to the paymentauthorization for added security (step 3204). The SEM sends the paymentauthorization to the EBPP system (step 3206), which is part of theelectronic account system in this embodiment. The EBPP system in turnsends the payment authorization to a financial institution (step 3208).This method is an improvement over conventional systems in many ways.The inclusion of an EPM on the payment authorization enhances securityfor both payer and biller. Because the identity of the payer isvalidated before the SEM is activated, the biller has increasedconfidence when sending bills and receiving payment.

[0160]FIG. 33 is a flowchart of another embodiment of an electronic billpayment method consistent with the present invention. A payer sendspayment authorization to his SEM (step 3302). The SEM can apply anelectronic postmark (EPM) to the payment authorization for addedsecurity (step 3304). The SEM sends the payment authorization to theEBPP system (step 3306), which is not part of the electronic accountsystem in this embodiment. The EBPP system in this embodiment could beoffered by a third party to the payer via the electronic account system.The EBPP system sends the payment authorization to a financialinstitution (step 3308).

[0161]FIG. 34 illustrates additional services that can be providedthrough an electronic account consistent with the present invention.Other services 3402 that can be provided via an electronic accountinclude mailing online 3404, NetPost.Certified 3405, shipping online3406, stamps online 3408, PC Postage 3409, and other services 3410.Mailing online 3404 is a service that receives a content file and anaddress list from a customer and produces a mailing to each address onthe address list. Mailing online can include a Card Store product.NetPost.Certified 3405 enables a customer to download a digitalcertificate onto a Smart Card for use in authenticating electronictransactions. Shipping online 3406 is a service that enables a customerto ship packages automatically and privately. Stamps online 3408 enablesa customer to purchase stamps. PC Postage 3408 enables a customer topurchase and print postage using a computer.

[0162] F. Certificate Authority for Proofing Identities

[0163] Systems consistent with the present invention provide acertificate authority for proofing the identity of an electroniccustomer. Using digital certificate software, the electronic accountsystem provides a digital certificate, described in detail below, to acustomer after the customer has been verified in-person as part of theelectronic account registration process. In this way, a digitalcertificate consistent with the present invention authenticates thecustomer's identity in a way that is not available in conventionalsystems.

[0164]FIG. 35 is a block diagram of a system for providing a certificateauthority for proofing identities consistent with the present invention.A digital certificate requestor 3502 sends a request for digitalcertificate 3504 to a digital certificate authority 3506. Digitalcertificate requester 3502 can be, for example, certificate software ora proofing workstation. In response to request for digital certificate3504, digital certificate authority 3506 sends a digital certificate3508 to digital certificate requestor 3502.

[0165]FIG. 36 is a block diagram of a digital certificate consistentwith the present invention. Digital certificate 3508 includes anidentifier of the customer 3602, a certificate serial number 3604, acertificate validity period 3606, a proofing workstation validation3608, a public key 3610, a certificate issuer identifier 3612, and acertificate status 3614. Certificate status 3614 can be, for instance,active, on hold, or revoked. The digital certificate can be, forexample, a well-known CCITT X.500 Section 509 Version 3 certificate.

[0166]FIG. 37 is a block diagram of a certificate authority consistentwith the present invention. Certificate authority 3506 contains knownsoftware to generate digital certificates as described above. Inaddition, certificate authority 3506 includes at least one proofingserver 3702 and at least one proofing workstation 3704. As describedabove, a customer having an electronic account can conduct electronictransactions and provide a digital certificate to third parties toverify the customer's identity. A third party can request verificationof the digital certificate via proofing workstation 3704, such as akiosk available in a Post Office. Proofing workstation 3704 communicateswith proofing server 3702 to verify the digital certificate and returnsthe verification to the third party via proofing workstation 3704. Thus,certificate authority 3506 enables third parties to proof the customer'sidentity using a digital certificate.

[0167]FIG. 38 is a block diagram of a proofing server consistent withthe present invention. Proofing server 3702 includes a certificatedirectory 3802, a certificate revocation list 3804, and an interfacewith proofing workstations 3806. Certificate directory 3802 is a list ofdigital certificates that have been issued by proofing server 3602,e.g., using known digital certificate software. Certificate revocationlist 3804 is a list of certificates that have been revoked, e.g., forfraudulent use generated by an electronic account system or a thirdparty. Interface with proofing workstations 3806 includes a private keyverifier 3808 that provides security by verifying a private key sentwith a verification request from a proofing workstation.

[0168]FIG. 39 is a block diagram of a proofing workstation consistentwith the present invention. Proofing workstation 3704 can be, forexample, a computer or kiosk available in a public place, such as a PostOffice. A third party wishing to proof a digital certificate can submita request to proofing workstation 3704, perhaps accompanied by a feepaid by credit card or smart card. Proofing workstation 3704communicates with proofing server 3702 to proof the digital certificateand return a validation to the third party. Proofing workstation 3704includes a central processing unit (CPU) 3902, an input device 3904(e.g., a keyboard), an output device 3906 (e.g., a printer or monitor),an interface with proofing servers 3908, a memory 3910, a credit cardreader 3914, and a smart card interface 3916. Memory 3910 includes aprivate key 3912. Private key 3912 is sent with proofing requests fromproofing workstation 3704 to proofing server 3702 to provide security.

[0169] While digital certificates consistent with the present inventionuse in-person identity validation using identification documents, manydifferent types of identity validation may be used consistent with thepresent invention. For example, biometric identification, such asfingerprinting or retinal scans, could be used.

[0170] Although the preferred embodiments of the present invention havebeen described in detail herein, it is to be understood that thesedescriptions are merely illustrative. Other embodiments of the inventionwill be apparent to those skilled in the art from consideration of thespecification and practice of the invention disclosed herein. It isintended that the specification and examples be considered as exemplaryonly, with a true scope and spirit of the invention being indicated bythe following claims.

What is claimed is:
 1. A method for determining a standardized physicaladdress of a user with an electronic account, comprising the steps of:sending a query from an address matching engine to an address matchingdirectory database; determining, by the address matching directorydatabase, the standardized physical address of the user based on thequery; sending the standardized physical address from the addressmatching directory database to the address matching engine; and linkingthe standardized physical address to the electronic account.
 2. Themethod of claim 1, wherein the query includes address informationprovided by the user.
 3. The method of claim 1, wherein the addressmatching directory database is created from a United States PostalService master address database.
 4. The method of claim 1, wherein thestandardized physical address includes a delivery point identificationkey.
 5. The method of claim 4, wherein the delivery point identificationkey corresponds to an entry in a United States Postal Service masteraddress database.
 6. A method for determining a standardized physicaladdress of a user with an electronic account, comprising the steps of:obtaining a delivery point identification key, the delivery pointidentification key corresponding to a physical address of the user;storing the delivery point identification key in the electronic account;sending the delivery point identification key to an address database;and receiving the standardized physical address corresponding to thedelivery point identification key from the address database.
 7. Themethod of claim 6, wherein the address database is a United StatesPostal Service master address database.
 8. The method of claim 6,wherein the obtaining step further comprises the substep of: obtainingthe delivery point identification key from an address matching engine.9. The method of claim 8, wherein the address matching engine is aUnited States Postal Service address matching engine.
 10. The method ofclaim 6, further comprising: retrieving updated standardized physicaladdress information from the address database using the delivery pointidentification key.
 11. A method for determining a standardized physicaladdress of a user with an electronic account, comprising the steps of:creating a static address database from a master address database, thestatic address database containing the standardized physical address ofthe user, wherein the standardized physical address comprises apredetermined set of data; obtaining an address of the user from theelectronic account; sending the address of the user to the staticaddress database; and receiving a delivery point identification keycorresponding to the address of the user, wherein the delivery pointidentification key can be used to obtain the standardized physicaladdress of the user from the static address database.
 12. The method ofclaim 11, wherein the master address database is a United States PostalService master address database.
 13. The method of claim 11, wherein thestatic address database is a United States Postal Service staticmonolithic address database.
 14. A method for determining a standardizedphysical address of a user with an electronic account, comprising thesteps of: accessing an address database containing the standardizedphysical address of the user, wherein the standardized physical addresscomprises a predetermined set of data; obtaining an address of the userfrom the electronic account; sending the address of the user to theaddress database; and receiving a delivery point identification keycorresponding to the address of the user, wherein the delivery pointidentification key can be used to obtain the standardized physicaladdress of the user from the address database.
 15. The method of claim14, wherein the address database contains a plurality of standardizedaddresses corresponding to a plurality of users, each standardizedaddress conforming to a standard format.
 16. The method of claim 15,wherein the standard format includes a street number, street name, city,state, and ZIP code.
 17. A method for determining a standardizedphysical address of a user with an electronic account, comprising thesteps of: obtaining an address of the user from the electronic account;sending the address of the user to an address database, wherein theaddress database contains the standardized physical address of the user;and receiving a delivery point identification key corresponding to theaddress of the user, wherein the delivery point identification key canbe used to obtain the standardized physical address of the user from theaddress database.
 18. The method of claim 17, wherein the addressdatabase is a United States Postal Service master address database. 19.The method of claim 17, further comprising: retrieving updatedstandardized physical address information from the address databaseusing the delivery point identification key.
 20. The method of claim 17,wherein the standardized physical address includes a street number,street name, city, state, and ZIP code.
 21. A method for delivering aphysical message in an electronic format to a plurality of users with anelectronic account and a physical address, comprising the steps of:receiving the physical message directed to the physical address for eachof the users; determining an electronic address for each of the usersfrom the physical address of each user; and sending the physical messagein an electronic format to the electronic address for each of the users.22. The method of claim 21, further comprising the step of: sending thephysical message to the physical address for each of the users.
 23. Themethod of claim 21, wherein the determining step further comprises thesubsteps of: generating a key corresponding to the user using theelectronic address, the key allowing access to an address database; andmatching the physical address from the address database using the key inorder to determine the electronic address.
 24. The method of claim 21,wherein the electronic address is a fax number.
 25. The method of claim21, wherein the electronic address is an e-mail addresses.
 26. Themethod of claim 21, wherein the electronic address is a telephonenumber.
 27. The method of claim 21, wherein the sending step furthercomprises the substep of: sending the physical message in an electronicformat via an e-mailbox repository.
 28. The method of claim 21, whereinthe sending step further comprises the substep of: sending the physicalmessage in an electronic format via an e-mail routing system.
 29. Themethod of claim 21, wherein the receiving step further comprises thesubstep of: receiving a physical address file containing the physicaladdress of each of the users.
 30. The method of claim 21, wherein thereceiving step further comprises the substep of: receiving a contentfile containing the physical message.
 31. The method of claim 21,wherein the receiving step further comprises the substeps of: receivinga physical address file containing the physical address of each of theusers; and receiving a content file containing the physical message. 32.The method of claim 21, further comprising the step of: creating ane-mail mailing list containing the electronic address for each of theusers.
 33. The method of claim 21, further comprising the step of:verifying the physical address of each user in an address matchingsystem.
 34. A method for delivering an electronic message in a physicalformat to a plurality of users with an electronic account and anelectronic address, comprising the steps of: receiving the electronicmessage directed to the electronic address for each of the users;determining a physical address for each of the users from the electronicaddress of each user; and sending the electronic message in a physicalformat to the physical address for each of the users.
 35. The method ofclaim 34, further comprising the step of: sending the electronic messageto the electronic address for each of the users.
 36. The method of claim34, wherein the electronic address is a fax number.
 37. The method ofclaim 34, wherein the electronic address is an e-mail addresses.
 38. Themethod of claim 34, wherein the electronic address is a telephonenumber.
 39. The method of claim 34, wherein the receiving step furthercomprises the substep of: receiving an electronic address filecontaining the electronic address of each of the users.
 40. The methodof claim 34, wherein the receiving step further comprises the substepof: receiving a content file containing the electronic message.
 41. Themethod of claim 34, wherein the receiving step further comprises thesubsteps of: receiving an electronic address file containing theelectronic address of each of the users; and receiving a content filecontaining the electronic message.
 42. The method of claim 34, furthercomprising the step of: creating an e-mail mailing list containing theelectronic address for each of the users.
 43. The method of claim 34,further comprising the step of: verifying the physical address of eachuser in an address matching system.
 44. A system for determining astandardized physical address of a user with an electronic account,comprising: a query sending component configured to send a query from anaddress matching engine to an address matching directory database; adetermining component configured to determine by the address matchingdirectory database, the standardized physical address of the user basedon the query; an address sending component configured to send thestandardized physical address from the address matching directorydatabase to the address matching engine; and a linking componentconfigured to link the standardized physical address to the electronicaccount.
 45. The system of claim 44, wherein the query includes addressinformation provided by the user.
 46. The system of claim 44, whereinthe address matching directory database is created from a United StatesPostal Service master address database.
 47. The system of claim 44,wherein the standardized physical address includes a delivery pointidentification key.
 48. The system of claim 44, wherein the deliverypoint identification key corresponds to an entry in a United StatesPostal Service master address database.
 49. A system for determining astandardized physical address of a user with an electronic account,comprising: a key obtaining component configured to obtain a deliverypoint identification key, the delivery point identification keycorresponding to a physical address of the user; a storing componentconfigured to store the delivery point identification key in theelectronic account; a sending component configured to send the deliverypoint identification key to an address database; and a receivingcomponent configured to receive the standardized physical addresscorresponding to the delivery point identification key from the addressdatabase.
 50. The system of claim 49, wherein the address database is aUnited States Postal Service master address database.
 51. The system ofclaim 49, wherein the key obtaining component further comprises: anengine key obtaining component configured to obtain the delivery pointidentification key from an address matching engine.
 52. The system ofclaim 51, wherein the address matching engine is a United States PostalService address matching engine.
 53. The system of claim 49, furthercomprising: a retrieving component configured to retrieve updatedstandardized physical address information from the address databaseusing the delivery point identification key.
 54. A system fordetermining a standardized physical address of a user with an electronicaccount, comprising: a creating component configured to create a staticaddress database from a master address database, the static addressdatabase containing the standardized physical address of the user,wherein the standardized physical address comprises a predetermined setof data; an obtaining component configured to obtain an address of theuser from the electronic account; a sending component configured to sendthe address of the user to the static address database; and a receivingcomponent configured to receive a delivery point identification keycorresponding to the address of the user, wherein the delivery pointidentification key can be used to obtain the standardized physicaladdress of the user from the static address database.
 55. The system ofclaim 54, wherein the master address database is a United States PostalService master address database.
 56. The system of claim 54, wherein thestatic address database is a United States Postal Service staticmonolithic address database.
 57. A system for determining a standardizedphysical address of a user with an electronic account, comprising: anaccessing component configured to access an address database containingthe standardized physical address of the user, wherein the standardizedphysical address comprises a predetermined set of data; an obtainingcomponent configured to obtain an address of the user from theelectronic account; a sending component configured to send the addressof the user to the address database; and a receiving componentconfigured to receive a delivery point identification key correspondingto the address of the user, wherein the delivery point identificationkey can be used to obtain the standardized physical address of the userfrom the address database.
 58. The system of claim 57, wherein theaddress database contains a plurality of standardized addressescorresponding to a plurality of users, each standardized addressconforming to a standard format.
 59. The system of claim 58, wherein thestandard format includes a street number, street name, city, state, andZIP code.
 60. A system for determining a standardized physical addressof a user with an electronic account, comprising: an obtaining componentconfigured to obtain an address of the user from the electronic account;a sending component configured to send the address of the user to anaddress database, wherein the address database contains the standardizedphysical address of the user; and a receiving component configured toreceive a delivery point identification key corresponding to the addressof the user, wherein the delivery point identification key can be usedto obtain the standardized physical address of the user from the addressdatabase.
 61. The system of claim 60, wherein the address database is aUnited States Postal Service master address database.
 62. The system ofclaim 60, further comprising: a retrieving component configured toretrieve updated standardized physical address information from theaddress database using the delivery point identification key.
 63. Thesystem of claim 60, wherein the standardized physical address includes astreet number, street name, city, state, and ZIP code.
 64. A system fordelivering a physical message in an electronic format to a plurality ofusers with an electronic account and a physical address, comprising: aphysical message receiving component configured to receive the physicalmessage directed to the physical address for each of the users; adetermining component configured to determine an electronic address foreach of the users from the physical address of each user; and anelectronic sending component configured to send the physical message inan electronic format to the electronic address for each of the users.65. The system of claim 64, further comprising: a physical sendingcomponent configured to send the physical message to the physicaladdress for each of the users.
 66. The system of claim 64, wherein thedetermining component further comprises: a generating componentconfigured to generate a key corresponding to the user using theelectronic address, the key allowing access to an address database; anda matching component configured to match the physical address from theaddress database using the key in order to determine the electronicaddress.
 67. The system of claim 64, wherein the electronic address is afax number.
 68. The system of claim 64, wherein the electronic addressis an e-mail addresses.
 69. The system of claim 64, wherein theelectronic address is a telephone number.
 70. The system of claim 64,wherein the sending component further comprises: a repository sendingcomponent configured to send the physical message in an electronicformat via an e-mailbox repository.
 71. The system of claim 64, whereinthe sending component further comprises: a routing system sendingcomponent configured to send the physical message in an electronicformat via an e-mail routing system.
 72. The system of claim 64, whereinthe receiving component further comprises: an address file receivingcomponent configured to receive a physical address file containing thephysical address of each of the users.
 73. The system of claim 64,wherein the receiving component further comprises: a content filereceiving component configured to receive a content file containing thephysical message.
 74. The system of claim 64, wherein the receivingcomponent further comprises: a physical address receiving componentconfigured to receive a physical address file containing the physicaladdress of each of the users; and a content file receiving componentconfigured to receive a content file containing the physical message.75. The system of claim 64, further comprising: a creating componentconfigured to create an e-mail mailing list containing the electronicaddress for each of the users.
 76. The system of claim 64, furthercomprising: a verifying component configured to verify the physicaladdress of each user in an address matching system.
 77. A system fordelivering an electronic message in a physical format to a plurality ofusers with an electronic account and an electronic address, comprising:a message receiving component configured to receive the electronicmessage directed to the electronic address for each of the users; adetermining component configured to determine a physical address foreach of the users from the electronic address of each user; and aphysical address sending component configured to send the electronicmessage in a physical format to the physical address for each of theusers.
 78. The system of claim 77, further comprising: an electronicaddress sending component configured to send the electronic message tothe electronic address for each of the users.
 79. The system of claim77, wherein the electronic address is a fax number.
 80. The system ofclaim 77, wherein the electronic address is an e-mail addresses.
 81. Thesystem of claim 77, wherein the electronic address is a telephonenumber.
 82. The system of claim 77, wherein the receiving componentfurther comprises: an address file receiving component configured toreceive an electronic address file containing the electronic address ofeach of the users.
 83. The system of claim 77, wherein the receivingcomponent further comprises: a content file receiving componentconfigured to receive a content file containing the electronic message.84. The system of claim 77, wherein the receiving component furthercomprises: an address file receiving component configured to receive anelectronic address file containing the electronic address of each of theusers; and a content file receiving component configured to receive acontent file containing the electronic message.
 85. The system of claim77, further comprising: a creating component configured to create ane-mail mailing list containing the electronic address for each of theusers.
 86. The system of claim 77, further comprising: a verifyingcomponent configured to verify the physical address of each user in anaddress matching system.
 87. A computer readable medium having computerreadable code embodied therein for determining a standardized physicaladdress of a user with an electronic account, the computer readable codecomprising: a sending module configured to send a query from an addressmatching engine to an address matching directory database; a determiningmodule configured to determine, by the address matching directorydatabase, the standardized physical address of the user based on thequery; a sending module configured to send the standardized physicaladdress from the address matching directory database to the addressmatching engine; and a linking module configured to link thestandardized physical address to the electronic account.
 88. A computerreadable medium having computer readable code embodied therein fordetermining a standardized physical address of a user with an electronicaccount, the computer readable code comprising: an obtaining moduleconfigured to obtain a delivery point identification key, the deliverypoint identification key corresponding to a physical address of theuser; a storing module configured to store the delivery pointidentification key in the electronic account; a sending moduleconfigured to send the delivery point identification key to an addressdatabase; and a receiving module configured to receive the standardizedphysical address corresponding to the delivery point identification keyfrom the address database.
 89. A computer readable medium havingcomputer readable code embodied therein for determining a standardizedphysical address of a user with an electronic account, the computerreadable code comprising: a creating module configured to create astatic address database from a master address database, the staticaddress database containing the standardized physical address of theuser, wherein the standardized physical address comprises apredetermined set of data; an obtaining module configured to obtain anaddress of the user from the electronic account; a sending moduleconfigured to send the address of the user to the static addressdatabase; and a receiving module configured to receive a delivery pointidentification key corresponding to the address of the user, wherein thedelivery point identification key can be used to obtain the standardizedphysical address of the user from the static address database.
 90. Acomputer readable medium having computer readable code embodied thereinmethod for determining a standardized physical address of a user with anelectronic account, the computer readable code comprising: an accessingmodule configured to access an address database containing thestandardized physical address of the user, wherein the standardizedphysical address comprises a predetermined set of data; an obtainingmodule configured to obtain an address of the user from the electronicaccount; a sending module configured to send the address of the user tothe address database; and a receiving module configured to receive adelivery point identification key corresponding to the address of theuser, wherein the delivery point identification key can be used toobtain the standardized physical address of the user from the addressdatabase.
 91. A computer readable medium having computer readable codeembodied therein for determining a standardized physical address of auser with an electronic account, the computer readable code comprising:an obtaining module configured to obtain an address of the user from theelectronic account; a sending module configured to send the address ofthe user to an address database, wherein the address database containsthe standardized physical address of the user; and a receiving moduleconfigured to receive a delivery point identification key correspondingto the address of the user, wherein the delivery point identificationkey can be used to obtain the standardized physical address of the userfrom the address database.
 92. A computer readable medium havingcomputer readable code embodied therein for delivering a physicalmessage in an electronic format to a plurality of users with anelectronic account and a physical address, the computer readable codecomprising: a receiving module configured to receive the physicalmessage directed to the physical address for each of the users; adetermining module configured to determine an electronic address foreach of the users from the physical address of each user; and a sendingmodule configured to send the physical message in an electronic formatto the electronic address for each of the users.
 93. A computer readablemedium having computer readable code embodied therein for delivering anelectronic message in a physical format to a plurality of users with anelectronic account and an electronic address, the computer readable codecomprising: a receiving module configured to receive the electronicmessage directed to the electronic address for each of the users; adetermining module configured to determine a physical address for eachof the users from the electronic address of each user; and a sendingmodule configured to send the electronic message in a physical format tothe physical address for each of the users.
 94. A system for determininga standardized physical address of a user with an electronic account,comprising: means for sending a query from an address matching engine toan address matching directory database; means for determining, by theaddress matching directory database, the standardized physical addressof the user based on the query; means for sending the standardizedphysical address from the address matching directory database to theaddress matching engine; and means for linking the standardized physicaladdress to the electronic account.
 95. A system for determining astandardized physical address of a user with an electronic account,comprising: means for obtaining a delivery point identification key, thedelivery point identification key corresponding to a physical address ofthe user; means for storing the delivery point identification key in theelectronic account; means for sending the delivery point identificationkey to an address database; and means for receiving the standardizedphysical address corresponding to the delivery point identification keyfrom the address database.
 96. A system for determining a standardizedphysical address of a user with an electronic account, comprising: meansfor creating a static address database from a master address database,the static address database containing the standardized physical addressof the user, wherein the standardized physical address comprises apredetermined set of data; means for obtaining an address of the userfrom the electronic account; means for sending the address of the userto the static address database; and means for receiving a delivery pointidentification key corresponding to the address of the user, wherein thedelivery point identification key can be used to obtain the standardizedphysical address of the user from the static address database.
 97. Asystem for determining a standardized physical address of a user with anelectronic account, comprising: means for accessing an address databasecontaining the standardized physical address of the user, wherein thestandardized physical address comprises a predetermined set of data;means for obtaining an address of the user from the electronic account;means for sending the address of the user to the address database; andmeans for receiving a delivery point identification key corresponding tothe address of the user, wherein the delivery point identification keycan be used to obtain the standardized physical address of the user fromthe address database.
 98. A system for determining a standardizedphysical address of a user with an electronic account, comprising: meansfor obtaining an address of the user from the electronic account; meansfor sending the address of the user to an address database, wherein theaddress database contains the standardized physical address of the user;and means for receiving a delivery point identification keycorresponding to the address of the user, wherein the delivery pointidentification key can be used to obtain the standardized physicaladdress of the user from the address database.
 99. A system fordelivering a physical message in an electronic format to a plurality ofusers with an electronic account and a physical address, comprising:means for receiving the physical message directed to the physicaladdress for each of the users; means for determining an electronicaddress for each of the users from the physical address of each user;and means for sending the physical message in an electronic format tothe electronic address for each of the users.
 100. A system fordelivering an electronic message in a physical format to a plurality ofusers with an electronic account and an electronic address, comprising:means for receiving the electronic message directed to the electronicaddress for each of the users; means for determining a physical addressfor each of the users from the electronic address of each user; andmeans for sending the electronic message in a physical format to thephysical address for each of the users.